@SomeBottle - thanks for the pull request! I was not aware of this behavior, and I would want your proposed behavior in our own application. Thanks for catching this and proposing a solution.

I have some suggestions:

1. Could you consider renaming table_header_fallback to table_infer_header?
2. Could you move the missing --escape-misc argument to a separate pull request?

@AlexVonB, @matthewwithanm - my preference would be to not infer <th> header rows by default so that round-trips between HTML and Markdown are symmetrical. What do you think?

@AlexVonB, @matthewwithanm - my preference would be to not infer <th> header rows by default so that round-trips between HTML and Markdown are symmetrical. What do you think?

yeah, that behavior is surprising to me

Thank you for your response! I've renamed the option and removed --escape-misc from argument parser in the recent commit.

Should I change the default value of the option to False? Looking forward to your reply.

@SomeBottle - yes, please change the default to not infer header rows from data rows unless specified by the user.

OK, I just set the default value of the option to False and changed corresponding test cases and docs.

@SomeBottle - thanks!

Looking through your code, I see this:

        is_headrow = (
            all([cell.name == 'th' for cell in cells])
            or (el.parent.name == 'thead'
                # avoid multiple tr in thead             # <----
                and len(el.parent.find_all('tr')) == 1)  # <----
        )

What is the thinking behind the check for multiple <tr> elements? Is the thinking that if a <thead> contains multiple <tr> rows, they are probably truly data rows instead of header rows?

@SomeBottle - thanks!

Looking through your code, I see this:

        is_headrow = (
            all([cell.name == 'th' for cell in cells])
            or (el.parent.name == 'thead'
                # avoid multiple tr in thead             # <----
                and len(el.parent.find_all('tr')) == 1)  # <----
        )

What is the thinking behind the check for multiple <tr> elements? Is the thinking that if a <thead> contains multiple <tr> rows, they are probably truly data rows instead of header rows?

Yes, considering the possibility of such an unusual situation, which is actually an invalid header for markdown table, I think it should be treated as a header missing case, and the rows should be regarded as data rows.

@SomeBottle - could you rebase/merge this branch to the latest state of develop? Thanks!

@chrispy-snps OK, I've rebased the branch.

@SomeBottle - thanks for your contribution!